[Previous] [Next] [Index] [Thread]

Re: how do I keep a browser from caching files

-----BEGIN PGP SIGNED MESSAGE-----

Daryl Hawes wrote:
> 
> This is my first time posting to this list. Hope that I am following
> procedure.
> 
>   My department is trying to run a program that will allow users to
> access sensitive data. We have the security/password part down, but
> most of the accesses will come fromunsecure lab room machines. DOes
> anyone know of a way, an HTML tag, a meta tag, or something that will
> instruct our university's Netscape 2.0 or better browsers not to cache
> the resulting files, so that if a user walks away from a machine
> someone else cannot come along and use the "back" button to view their
> information?
> 
> Thank you in advance,
> D'aryl Hawes
> hawes@scus1.ctstateu.edu

Let me recap my understanding of your problem:

(1) since the web page is secure, it undoubtedly requires 
    a password;

(2) therefore you don't want the file cached, so that if 
    the user hits BACK button it will force the user to 
    reenter password (since file is NOT cached in memory); 

(3) that is maybe why you said, ``Does anyone know of a 
    way, an HTML tag, a meta tag, or something that will 
    instruct our university's Netscape 2.0 or better 
    browsers not to cache the resulting files, so that if 
    a user walks away from a machine someone else cannot 
    come along and use the "back" button to view their 
    information?''

If a secure file requiring HTML password access is cleared 
from cache, then hitting BACK button is the same as hitting 
site for first time *usually*, correct?

Anyway to answer your question, I'd say if the answer to 
above is ``yes'' then the solution proposed by list member 
willday@rom.oit.gatech.edu (Will Day) which causes server to 
send ``Pragma: no-cache'' *does work* for your expressed 
purpose when he wrote,

>         <HEAD>
>         <META HTTP-EQUIV="Pragma" CONTENT="no-cache">
>         </HEAD

I implemented Mr. Day's solution in a web page yesterday, 
but couldn't tell if it was working because I'm on a T-1 
(or is it T3) connection and it loads too fast to see if it's 
caching or not.  When I went home last night and loaded it on 
my 486-DX2/66 system at 14.4, it was (almost painfully) 
apparent that the site was *not* cached in memory (since 
every time I hit a link even within the same HTML file, or 
hit BACK to revisit a link, it rehit entire HTML page).

Two benefits to myself of this ability not to cache, is (a) 
the web page changes often, so I don't have to worry about 
users having a previous version cached; and (b) taking this 
extra step to prevent caching *might* help to show that 
reasonable steps were taken to prevent web page copyright 
infringement since no trace of the page is left on countless 
hard drives, allowing users to claim it was made easy for 
them to copy the page for later ``fair use'' by them.  (This 
second ``benefit'' may prove not to be valid at all.)

Therefore to answer your question, going to a secure web page 
(password protected) site MIGHT afford some protection to the 
user (but not necessarily always depending on password scheme).  
Hitting BACK key would be like *hitting site for first time*.  
(HOWEVER, I'm personally dubious about HTML password schemes.)  

If your intent is to keep the site and/or I.P. number used in 
URL location a secret from someone who walks up to a machine 
and hits BACK (i.e., to excise it from HISTORY), then Larry 
Masinter <masinter@parc.xerox.com> is correct when cautioning 
that your history will remain intact.

If it's history you're concerned with, I'd make a habit of 
switching windows and erasing your ``history.db'' file (or 
using Norton or other program to ``wipe'' it to military 
specs) before leaving the workstation, even writing a 
script/macro/batch-file to routinely do the deed.  For very 
sensitive data, the above is at best a ``Mickey Mouse'' 
solution and really of benefit only if the data is ``sort of 
sensitive'' (such as marketing data, but never military or 
company trade secret data to name two of many examples).

Gene

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMX0Uxs4N33uf66GRAQH98wP7BajSkNT2KyB9rMa1W8w4ubs6jxP3el2M
WxWs7B4midechhBdmuNAhBgmVOY4mPtPId4I7ykIe8+LXMOPAZmiNKyhUEF704Mv
lfhZN1Gq+4/PTgkiUch+NUveIWg2qQm51mdtdzthmavQAg5qcFmXlFAAzI32kzqn
MVw/0z/gUpY=
=TWYO
-----END PGP SIGNATURE-----

-- 
``Imagine if every Thursday your shoes exploded if you tied them 
  the usual way. This happens to us all the time with computers, 
  and nobody thinks of complaining.''  -Jeff Raskin

   ______                  gene@cup.hp.com
  /\__  _\                   ingram@pubs.holosys.com
  \/_/\ \/     ___      __   _ __    __      ___ ___
     \ \ \   /' _ `\  /'_ `\/\`'__\/'__`\  /' __` __`\
      \_\ \__/\ \/\ \/\ \L\ \ \ \//\ \L\.\_/\ \/\ \/\ \
      /\_____\ \_\ \_\ \____ \ \_\\ \__/.\_\ \_\ \_\ \_\
      \/_____/\/_/\/_/\/___L\ \/_/ \/__/\/_/\/_/\/_/\/_/
                        /\____/
________________________\_/__/____________________________________
PGP UserID: "Gene Ingram <gene@cup.hp.com>"
Key Size: 1024 bits; Creation date: 21 March 1996; KeyID: 9FEBA191
Key fingerprint:  93 E1 15 E6 35 BC B2 84  B2 7B 39 76 29 72 32 72

--3D signature created courtesy of ``Figlet Ascii Font Converter''
  <http://mediacube.datacom.de/cgi-bin/moniteurs/figlet>
Follow-Ups: References: